Informe Técnico Exhaustivo

1. Introducción y Alcance

Este documento proporciona un análisis técnico detallado del módulo de gestión de profesores del sistema OTEC. El objetivo es desglosar todos los componentes, lógicas, estructuras de datos e interacciones para permitir una comprensión profunda y la replicación exacta del módulo. El análisis se basa en los archivos form_profesor.php, ver_profesor.php, asignar_cursos.php, asignar_profesor_subtema.php y los documentos de directrices y estructura de la base de datos.

2. Arquitectura de Datos

La funcionalidad del módulo de profesores se sustenta en un conjunto de tablas interrelacionadas que almacenan desde los datos personales del profesor hasta sus asignaciones y documentos.

2.1. Tablas Principales Involucradas

• profesores: Tabla central que almacena la información personal y de contacto de cada profesor.
• profesor_documentos: Almacena los documentos adjuntos de un profesor (CV, RUT, títulos, etc.).
• cursos_profesores: Tabla de enlace que gestiona la asignación de un profesor a un curso completo. Incluye detalles administrativos y financieros de la asignación.
• subtemas_curso: Aunque su propósito principal es definir el contenido de un curso, contiene el campo profesor_id, vinculando directamente a un profesor con una clase o actividad específica.
• cursos_sence: Tabla maestra de cursos, consultada para obtener los nombres y detalles de los cursos a asignar.

2.2. Diagrama de Relaciones (Conceptual)

[cursos_sence] 1--* [cursos_profesores] *--1 [profesores]
      |                                           |
      |                                           *--1 [profesor_documentos]
      |
      *--- [temas_curso] 1--* [subtemas_curso] *--1 [profesores] (Opcional)
            

• Un Profesor puede tener múltiples Documentos. (profesores.id -> profesor_documentos.profesor_id)
• Un Profesor puede estar asignado a múltiples Cursos, y un Curso puede tener múltiples Profesores. (Relación muchos a muchos a través de cursos_profesores)
• Un Profesor puede ser asignado directamente a un Subtema específico de un curso. (profesores.id -> subtemas_curso.profesor_id)

2.3. Descripción Detallada de Tablas y Campos

A continuación, se detalla la estructura y propósito de los campos clave en las tablas más relevantes para este módulo, según el fichero estructura de tablas curso sence.txt.

Tabla: profesores

Tabla: profesor_documentos

Tabla: cursos_profesores

Esta tabla es fundamental para la interacción, ya que crea la relación formal entre un profesor y un curso, con todos sus detalles contractuales y financieros.

3. Lógica de Negocio y Flujos de Proceso

3.1. Creación y Edición de un Profesor (form_profesor.php)

Este archivo es el corazón del módulo, manejando tanto la creación de nuevos profesores como la actualización de los existentes. El flujo es el siguiente:

1. Detección de Modo: El script primero verifica si existe un parámetro $_GET['id']. Si es así, entra en modo "Edición"; de lo contrario, está en modo "Creación".
2. Recopilación de Datos del Formulario: Al enviar el formulario ($_POST['guardar_profesor']), se recogen todos los datos de los campos del formulario.
3. Validación: Se realizan validaciones básicas, como comprobar que los campos obligatorios (RUT, nombre, apellido paterno) no estén vacíos.
4. Prevención de Inyección SQL: Todos los datos de tipo texto se escapan usando $mysqli->real_escape_string() antes de construir la consulta SQL.
5. Gestión de Transacciones: Todas las operaciones de base de datos se envuelven en una transacción ($mysqli->begin_transaction()), garantizando la integridad de los datos. Si cualquier paso falla, se ejecuta un $mysqli->rollback().
6. Creación de Directorios:
   • Para un nuevo profesor, primero se inserta el registro en la tabla profesores para obtener el $profesor_id. Luego, se crea una estructura de directorios única.
   • Para un profesor existente, se verifica si el nombre o apellido ha cambiado. Si es así, se renombra el directorio principal del profesor para mantener la consistencia.
7. Procesamiento de Foto de Perfil:
   • Se valida la extensión y el tamaño del archivo de imagen.
   • Se mueve el archivo subido al directorio de fotos del profesor.
   • Se actualiza el campo foto_perfil en la tabla profesores con la nueva ruta.
8. Procesamiento de Documentos:
   • El formulario permite la carga de múltiples documentos simultáneamente.
   • Se itera sobre cada archivo subido, se valida su extensión y tamaño.
   • Cada archivo válido se mueve al subdirectorio documentos/.
   • Se inserta un nuevo registro en la tabla profesor_documentos para cada archivo, vinculándolo al profesor_id.
9. Confirmación o Reversión: Si todos los pasos son exitosos, se confirma la transacción con $mysqli->commit(). Si ocurre cualquier error (lanzado como una Exception), se captura y se revierte la transacción.

3.2. Asignación de Profesor a Subtema (asignar_profesor_subtema.php)

Este es un script de backend diseñado para ser llamado vía AJAX. Su función es crucial para la granularidad de la asignación.

• Entrada: Recibe subtema_id y profesor_id vía POST.
• Lógica de Desasignación: Si profesor_id es 0, se interpreta como una desasignación y se actualiza subtemas_curso.profesor_id a NULL.
• Lógica de Asignación en Cascada (Implícita): Esta es una interacción clave. Al asignar un profesor a un subtema:
  1. Primero, actualiza subtemas_curso.profesor_id.
  2. Luego, verifica si ya existe una asignación para ese profesor en el curso padre (tabla cursos_profesores).
  3. Si no existe, crea automáticamente un registro en cursos_profesores para asegurar que el profesor esté formalmente vinculado al curso general. Esto evita inconsistencias y mantiene la integridad relacional del sistema.
• Respuesta: Devuelve una respuesta JSON indicando éxito o fracaso.

4. Estructura de Archivos y Directorios

La organización de los archivos de los profesores es fundamental para evitar colisiones de nombres y mantener un sistema ordenado. La lógica está implementada en form_profesor.php.

4.1. Estructura General

Todos los archivos relacionados con un profesor se almacenan dentro de un directorio base, típicamente llamado profesor/ en la raíz del proyecto. Dentro de este, cada profesor tiene su propio directorio.

4.2. Nomenclatura del Directorio del Profesor

El nombre del directorio de cada profesor sigue un formato estandarizado para garantizar unicidad y fácil identificación:

• {ID}: Es el id autoincremental de la tabla profesores.
• {nombre_sanitizado} y {apellido_paterno_sanitizado}: Son las versiones del nombre y apellido procesadas por la función sanitizar_nombre().

La función de sanitización (extraída de form_profesor.php) convierte el texto a minúsculas, reemplaza espacios con guiones bajos y elimina caracteres especiales y acentos. Esto previene problemas con los sistemas de archivos.

4.3. Subdirectorios y Rutas de Archivos

Dentro del directorio de cada profesor, se crea la siguiente estructura:

• /foto/: Contiene la foto de perfil del profesor. El archivo se nombra con un timestamp para evitar problemas de caché y colisiones (ej. foto_perfil_1686502000.png). La ruta completa guardada en profesores.foto_perfil sería profesor/(id profesor)_(nombre profesor)_(apellido paterno profesor)/foto/foto_perfil_1686502000.png.
• /documentos/: Almacena todos los documentos adjuntos. Los nombres de archivo también se hacen únicos, típicamente prefijados por el tipo de documento y un timestamp (ej. curriculum_cv_juan_perez_1686502100.pdf). La ruta completa se guarda en profesor_documentos.ruta_archivo.
• /material_didactico/: Directorio creado para futuro material didáctico que el profesor pueda subir.

5. Borrado Lógico

El sistema prioriza la integridad de los datos y el historial, por lo que implementa el borrado lógico en lugar del borrado físico (DELETE FROM ...) en las entidades principales.

5.1. Mecanismo de Implementación

El borrado lógico se gestiona a través de una columna estado presente en tablas clave como profesores, profesor_documentos, cursos_profesores, etc. Esta columna es de tipo ENUM('activo', 'inactivo').

• Activo: El registro es visible y funcional en la operativa normal del sistema.
• Inactivo: El registro se considera "borrado". No se muestra en los listados principales y no participa en las operaciones estándar, pero permanece en la base de datos.

5.2. Flujo de Operación

1. Eliminación desde la UI: Cuando un usuario hace clic en "Eliminar" un profesor o un documento, el sistema no ejecuta una sentencia DELETE.
2. Actualización de Estado: En su lugar, ejecuta una sentencia UPDATE para cambiar el valor de la columna estado de 'activo' a 'inactivo'. El formulario de edición del profesor (form_profesor.php) incluye un campo de selección para cambiar este estado.
3. Filtrado en Consultas: Todas las consultas que recuperan listas de datos (como en ver_profesor.php o listados generales) deben incluir una cláusula WHERE estado = 'activo' para mostrar únicamente los registros válidos.

5.3. Interacciones en Cascada del Borrado Lógico

El borrado lógico de un profesor tiene implicaciones en cascada que deben ser manejadas por la lógica de la aplicación, ya que las restricciones ON DELETE CASCADE de la base de datos no se activan.

1. Profesor Inactivo: Si se marca un profesor como inactivo:
   • Asignaciones a Cursos (cursos_profesores): Las asignaciones existentes a cursos no se eliminan, pero al consultar los profesores de un curso, se debe hacer un JOIN con la tabla profesores y filtrar por profesores.estado = 'activo'. Esto efectivamente "oculta" la asignación sin perder el historial.
   • Asignaciones a Subtemas (subtemas_curso): De manera similar, aunque el profesor_id permanezca en la tabla subtemas_curso, las interfaces que muestren el profesor de un subtema deben verificar el estado de dicho profesor.
   • Documentos (profesor_documentos): Los documentos del profesor permanecen en la base de datos pero se vuelven inaccesibles a través de la interfaz del profesor.

6. Interfaz de Usuario y Estándares de Diseño

La interfaz sigue las directrices generales del sistema para mantener la consistencia visual y de experiencia de usuario.

6.1. Paleta de Colores Corporativos

Los colores utilizados se basan en la paleta definida en directrices.txt , que se corresponde con los colores estándar de Bootstrap para una rápida implementación.

6.2. Estructura y Componentes de UI

• Secciones de Formulario: Los formularios largos, como form_profesor.php, se dividen en secciones lógicas utilizando una div con la clase .form-section. Cada sección tiene un encabezado distintivo (.section-title) con el color primario de fondo.
• Botones de Acción Fijos: Los botones principales del formulario (Guardar, Cancelar) se agrupan en un contenedor con la clase .btn-fixed-group, que los posiciona de forma fija en la esquina inferior derecha de la pantalla para un acceso constante.
• Campos Obligatorios: Los campos requeridos en los formularios se marcan visualmente añadiendo la clase .required a su label, la cual agrega un asterisco rojo.
• Vista de Perfil (ver_profesor.php): La ficha de un profesor utiliza un diseño de "tarjeta de perfil" con una cabecera prominente (.profile-header) que muestra la foto, nombre, especialidad y estado. La información detallada se organiza en pestañas (Datos Personales, Documentos, Cursos Asignados) para una navegación limpia.

7. Seguridad

El módulo incorpora varias medidas de seguridad para proteger la integridad de los datos y prevenir ataques comunes.

• Prevención de Inyección SQL: Como se mencionó, se utiliza $mysqli->real_escape_string() en todas las entradas de usuario antes de incluirlas en consultas SQL.
• Gestión de Transacciones: El uso de transacciones en operaciones complejas (creación/edición de profesor) asegura que la base de datos no quede en un estado inconsistente si una parte del proceso falla.
• Validación de Carga de Archivos: Se implementan validaciones del lado del servidor para el tipo de archivo (extensión) y el tamaño máximo permitido, tanto para las fotos de perfil como para los documentos, para prevenir la carga de archivos maliciosos o excesivamente grandes.